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[57] 



ABSTRACT 



A hierarchical communication network management system 
is structured by a plurality of agents and sub-managers 
connected to lower communication networks and an inte- 
gration manager connected to a higher communLcation net- 
work. Each of the sub-managers functions as an agent to the 
integration manager and functions as a manager to each 
agent, so that it becomes possible to employ a Simple 
Network Management Protocol (SNMP) between each 
agent and its sub-manager and between a sub-manager and 
the integration manager. 

17 Claims, 39 Draiving She^s 
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FIG.4 



SUBMANAGER-MIB-EXAMPLE DEFINmONS : : = BEGIN 
IMPORTS 

enterprises, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks 

FROM RFC1155-SMI 
OBJECT-TYPE 

FROM RFC-1212 
Displ^String, IfEntry, AtEntry, IpAddrEntry, IpRouteEntry, 
ipNet I oMediaEntry, PhysAddress, TcpConnEntry. UdpEntry, EgpNeighEntry 

FROM RFC12f3-MIB 
TRAP-TYPE 

FROM RFC-1215: 

hitachi OBJECT IDENTIFIER :: = {enterprises 116} 
systemExMib OBJECT IDENTIFIER : : = { hitachi 5 } 
hiuxwe2 OBJECT IDENTIFIER : : = { systemExMib 5 } 
cometMibs OBJECT IDENTIFIER = {hiuxwe2 1} 
hierarchy OBJECT IDENTIFIER : : = { cometMibs 4 ) 
standard OBJECT IDENTIFIER : : = { hierarchy 1 } 
extension OBJECT IDENTIFIER : : = { hierarchy 2 } 
smgTotal OBJECT IDENTIFIER : : = { standard 1 } 
smglpNode OBJECT IDENTIFIER : : = { standard 2 } 

smgSumTcp OBJECT IDENTIFIER : : = { extension 1 } 

- SUB-MANAGER PERIODICAL COLLECTION MIB GROUP 
( The Submanager Collection group ) 

~ STRUCTURED BY THE SUB-MANAGER TOTAL GROUP AND THE 
SUB-MANAGER IP NODE GROUP 

- SUB-MANAGER TOTAL GROUP 
(the Submanager Total group) 

smgTotalManagedNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE NUMBER OF IP NODE FOR MANAGEMENT " 
: : = { smgTotal 1 } 

smgTotalCriticalNodeNumber OBJECT-TYPE 
SYNTAX INTEGER ( 0.. 65535 ) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

- SHOWS THE NUMBER OF NODE WHICH IS CRITICAL WITH 
THE SUB-MANAGER" 
: : = { smgTotal 2 } 
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smgTotalMarginalNodeNumber OBJECT-TYPE 
SYNTAX INTEGER ( 0.. 65535 



FIG.5 

_JJE 
535) 



ACCESS read-onfy 
STATUS mandatory 
DESCRIPTION 

- SHOWS THE NUMBER OF NODES IN WHICH THERE IS A TCP 
/ IP INTERFACE WHICH CAN COMMUNICATE WITH THE SUB- 
MANAGER BUT WHICH ARE NOT OPERATING" 

: : = { smgTotal 3 } 

smgTotalNormalNodeNumber OBJECT-TYPE 
SYNTAX INTEGER ( 0..65535 ) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"SHOWS THE NUMBER OF NODES IN WHICH ALL THE TCP/ 
IP INTERFACES ARE OPERATING " 

: : = { smgTotal 4 } 

smgTotalRouterNodeNumber OBJECT-TYPE 
SYNTAX INTEGER { 0.,65535 ) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE NUMBER OF ROUTERS WHICH ARE WITHIN THE 
MANAGEMENT RANGE OF THE SUB-MANAGER " 
: : = { smgTotal 5 } 

smgTotalSnmpSupportNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

*SHOWS THE NUMBER OF NODES WHICH ARE LOADED WITH 
SNMP WITHIN THE MANAGEMENT RANGE OF THE SUB- 
MANAGER " 

: : = { smgTotal 6 } 

- SUB-MANAGER IP NODE GROUP 
(the Submanager IpNode group) 

smglpNodeTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SmglpNodeEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

- SHOWS A LIST OF INFORMATION RELATING TO THE IP NODE 
WITHIN THE MANAGEMENT RANGE OF THE SUB-MANAGER " 

: : = { smglpNode 1 } 

SmglpNodeEntry OBJECT-TYPE 
SYNTAX SmglpNodeEntry 
ACCESS not-accessibte 
STATUS mandatory 
INDEX { smglpNodelndex } 
' Nbdef-^"- " * 



: : =5 { smglp^ 
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FIG.6 

SmglpNodeEntry : : = SEQUENCE ( 

smglpNodelndex INTEGER 
^ smglpNodeContext Display String 

smalpNodelndex OBJECT-TYPE 
SYNTAX INTEGER (..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"A UNIQUE VALUE FOR EACH SYSTEM 
THIS VALUE MUST BE CONSTANT UNTIL THE SUB- 
MANAGER HAS BEEN RE-INITIALIZED" 
: : = { SmglpNodeEntry 1 } 

smglpNodeContext OBJECT-TYPE 
SYNTAX DisplayString 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"AN ENTRY WHICH INCLUDES INFORMATION FOR EACH IP 

NODE WITHIN THE MANAGEMENT RANGE 
THE FOLLOWING INFORMATION ARE INCLUDED: 
{ 1 ) IP ADDRESS : SHOWS THE IP ADDRESS USED FOR 
' THE INTEGRATION MANAGER TO 

COMMUNICATE WITH THE HOST 
A SOFTWARE LOOP-BACK ADDRESS IS 
NOT USED ^ ^ 

( 2 ) HOST NAME : SHOWS THE HOST NAME OF THE IP 

NODE WITHIN THE MANAGEMENT RANGE 
A NAME DEFINED IN THE / etc / hosts 
WITHIN THE HOST OF WHICH SUB- 
MANAGER IS OPERATING IS USED. ^ 
IF THE NAME IS NOT DEFINED. THIS 
ITEM BECOMES A BLANK 

( 3 ) STATUS : SHOWS THE STATUS OF THE IP NOCC 
^ ' WITHIN THE MANAGEMENT RANGE 

THERE ARE THE FOLLOWING STATUSES : 

(a) NORMAL (Normal) 

(b) MARGINAL (Marginal) 
(c j CRITICAL (Critical V 

( 4 ) PING RESPONSE TIME : SHOWS A RESPONSE TIME OF 
^ ^ THE PING TO THE IP NODE 

(5) SNMP SUPPORT ^ ^ 
INFORMATION: SHOWS WHETHER THE IP NODE OF 

THE MANAGEMENT RANGE SUPPORTS 
THE SNMP OR NOT 

THERE ARE THE FOLLOWING VALUES : 

(a) SUPPORT (snmp) 

(b) NOT SUPPORT "TnonsnmpJ 

<6) ROUTER INFORMATION: SHOWS WHETHER THE IP NODE ^ 
^ ' WITHIN THE MANAGEMENT RANGE 

IS A ROUTER OR NOT 
THERE ARE THE FOLLOWING 
VALUES : 



(a) ROUTER (router) 
\b\ NOT A ROUTER (host) 
HOWN BELOW 



AN EXAMPLE OF OUTPUT IS SHC 

203.200.100.150. hostOOl Normal 10 nonsnmp router' 

- { SmglpNodeEntry 2 } 
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FIG.7 

- SUB-MANAGER REAL-TIME COLLECTION MIB GROUP 
(The Submanager Summary Tcp group) 

smgSumTcpTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SmgSumTcpEntry 
ACCESS not-accessible 
STATUS mandatoty 
DESCRIPTION 

" SHOWS THE LIST OF TCP COLLECTION WITHIN THE 
MANAGEMENT RANGE OF THE SUB-MANAGER " 
: : = { smgSumTcp 1 } 

smaSumTcpEntry OBJECT-TYPE 
SYNTAX SmgSumTcpEntry 
ACCESS not-accessible 
STATUS mandatory 

INDEX { smgSumTcpServerlpAddress, smgSumTcpServerPortNumber. 

smgSumTcpClientlpAddress. smgSumTcpClierrtPortNumber } 
: : = { smgSumTcpTable 1 ) 

SmgSumTcpEntry : : = SEQUENCE { 

igSumTcpJ 
IpAddress, 



smgSumTcpServerlpAddress 
IpAddress, 



smi 



igSumTcpServerPortNumber 

Integer. 



smqSumTcpCHentlpAddress 

ipAddress, 
smgSumTcpClientPortNumber 

INTEGER. 
smgSumTcpContext 

Display String 

SmgSumTcpServerlpAddress OBJECT-TYPE 
SYNTAX IpAddress 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"SHOWS THE IP ADDRESS AT WHICH THE TCP CONNECTION IS 
OPENED " 
: : = { SmgSumTcpEntry 1 } 

SmgSumTcpServerPortNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"SHOWS THE PORT NUMBER WHICH IS USED BY THE NODE 
DEFINED BY SmgSumTcpServerlpAddress " 
: : = { SmgSumTcpEntry 2 } 
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FIG.9 

( g ) fin Wait 1(6): IS WAITING FOR A DISCON- 

NECTION REQUEST FROM 
THE OTHER TCP OR HAS 
ISSUED A DISCONNECTION 
REQUEST AND IS WAITING 
FOR ACK OF THIS REQUEST 

(h) fin Wait2(7): IS WAITING FOR A DISCON- 

NECTION REQUEST FROM 
THE OTHER TCP 
( i ) close Walt ( 8 ) : IS WAITING FOR A DISCON- 
NECTION REQUEST FROM 
THE USER 

(j) last Ack(9): IS WAITING FOR ACK FROM 
THE OTHER TCP TO A DIS- 
CONNECTION REQUEST 
(k) closing (10): IS WAITING FOR ACK FROM 
THE OTHER TCP TO A DIS- 
CONNECTION REQUEST 
( I ) timeWart ( 11 ) : IS WAITING UNTIL THE ACK 
ISSUED FROM THIS SIDE 
HAS REACHED THE OTHER 
PARTY AND HAS BEEN 
PROCESSED 

( 4 ) IP ADDRESS ( PART 2 ) : SHOWS THE IP ADDRESS OF THE IP 

NODE WHICH OPENS THE TCP CON- 
NECTION ( THE OTHER PARTY OF 
THE NODE DEFINED IN THE IP 
ADDRESS n ) ) 

( 5 ) PORT NUMBER ( PART 2 ) : SHOWS THE PORT NUMBER WHICH 

IS USED BY THE IP NODE DEFINED 
IN ( 5 ) IN THIS TCP CONNECTION 

( 6 ) STATUS ( PART 2 ) : SHOWS THE STATUS OF THE TCP CON- 

NECTION WHICH IS OPENED BY THE IP 

NODE DEFINED IN ( 5 ) 

THE DEFINED VALUE IS DEFINED IN (4) 

( 7 ) SERVICE NAME : SHOWS THE SERVICE NAME WHICH USES 

THIS TCP CONNECTION 
THE SERVICE NAME USED IS THE NAME 
DEFINED IN THE / etc / services OF THE HOST 
OF WHICH SUB-MANAGER IS OPERATING 

AN EXAMPLE OF OUTPUT IS SHOWN BELOW 

203. 200. 100. 150 5648 established 200. 158. 123. 203 6300 unknown 

ftp- 

: : = { smgSumTcpEntry 5 } 
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FIG.10 

- SUB-MANAGER EXTENSION TRAPS ( the submanager specific traps ) 

smgCreateSystemTrap TRAP-TYPE 
ENTERPRISE submanager 
VARIABLES { smglpNodelndex ) 
DESCRIPTION 

" THE TRAPS ARE USED FOR POSTING THAT A SYSTEM 
HAS BEEN ADDED 

smglpNodelndex IS THE INDEX HELD BY THE ADDED 
SYSTEM - 

1 

smgDeleteSystemTrap TRAP-TYPE 
EISTTERPRISE submanager 
VARIABLES { smglpNodelndex } 
DESCRIPTION 

" THE TRAPS ARE USED FOR POSTING THAT A SYSTEM 
HAS BEEN DELETED 

smglpNodelndex IS THE INDEX HELD BY THE ADDED 
SYSTEM ■ 

: := 2 

smglntermedlaiyTrap TRAP-TYPE 

ENTERPRISE submanager 
VARIABLES { smgTrapLlsl } 
DESCRIPTION 
" RELAY TRAP 

VALUES OF THE ENTERPRISE CODE (enterprise) OF THE 
AGENT WHICH HAS ISSUED A TRAP TO BE RELAYED, 
THE NETWORK ADDRESS { agent-addr ), THE STANDARD 
TRAP NUMBER (generic-trap) AND THE EXTENSION TRAP 
NUMBER (specTficTrapi ARE SET TO THE variable-bindings 
FIELD AS THE VALUES OF smgEnterprise, smgAgentAddr, 
smgGenericTrap, AND smgSpecificTrap RESPECTIVELY 
THE VALUES OF THE variable-bindings FIELD OF THE 
RELAY TRAP CONSTITUTE A PART OF THE variable- 
bindings FIELD OF THE RELAY TRAP AND ARE RELAYED 
TO THE MANAGER 

: : = 3 

SmgTrap : : = 

SEQUENCE { 
smglpNodelndex, 
smgEnteiprise, 
smgAgentAddr, 
smgGenericTrap, 
smgSpeafficTrap, 
^ vanableBindings 

SmgTrapList : : = 

SEQUENCE OF 
SmgTrap 

END 
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REMARKS 


PERIODICAL 
COLLECTION 
MIB 


REAL-TIME 

COLLECTION 

MIB 


MANAGEMENT OBJECT 
NAME OF THE SUB- 
MANAGER EXTENSION 
MIB TO BE CONVERTED 


smglpNodeContext 


smgSumTcpContext 

SfngSumTcpServerlpAddress 

SmgSumTcpServerPortNumber 

SmgSumTcpClientlpAddress 

SmgSumTcpClientPortNumber 


INFORMATION TO BE COLLECTED 


OTHERS 


/ etc / hosts 
FILE 


ping 


1 


i 


1 


1 


1 


/ etc / sen^ices 
FILE 


MIB-II OBJECT NAME 


2 

o5 

^ w 


1 


sysObjectlD 


ifNumber 


ifType 


ifOperStatus 


IpForwardIng 


tcpConnState 

(tcpConnLocalAddress) 

(tcpConnLocalPort) 

(tcpConnRemAddress) 

(tcpConnRemPort) 


ITEM 


NUMBER 
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FIG.17 

MANAGEMENT RANGE MONITORING SYSTEM (MAIN) 



C START 3 



600 



INITIALIZING THE 

MANAGEMENT 

RANGE 



610 



LOOP UNTIL AN 
END REQUEST 
HAS BEEN 
RECEIVED 



MONITORING OF 
THE MANAGEMENT 
RANGE 



'620 



TOTAL 

PROCESSING 



630 



UPDATING THE 

MANAGEMENT 

RANGE 



'640 



C END ) 
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( START ^ 



FIG.18 

INITIALIZATION OF THE MANAGEMENT RANGE 



REFER TO 
THE 

ENVIRONMENT 
SETTING RLE 



SET THE 
MANAGEMENT 
RANGE TABLE 



OBTAIN 
atNetAddress 
FROM THE 
SELF-AGENT 
FUNCTION OF 
THE SUB- 
MANAGER 
ITSELF 



'650 



'651 



652 



653 



LOOP BY THE 
NUMBER OF 
atNetAddress 
DURING THE 
PERIOD 
WHILE A 
VACANT 
ENTRY EXISTSI 
IN THE 

MANAGEMENT 
WIOE TAPIE 



654 



YES 



IS THE VALUE / 
OF / 
atNetAddress / 
INCLUDED IN / 
THE \ 
MANAGEMENT \ 
ADDRESS \ 
RANGE? \ 



655 



ISSUE ping 
TO THE IP 
NODE OF THE 
Vy^UE OF 
atNetAddress 



656 



YES 



IS THERE A 
RESPONSE 
TO THE 
PING ? 



C END ) 



.657 



SET THE VALUE 
OF atNetAddress 
TO THE IP 
ADDRESS IN 
THE VACANT 
ENTRY OF THE 
MANAGEMENT 
RANGE TABLE 



658 



ISSUE (ADD) 
THE SUB- 
MANAGER 
EXTENSION 
TRAP TO THE 
INTEGRATION 
MANAGER 



.659 



SET THE 
FOLLOWING 
VALUES BY 
REFERRING TO 
THE 

MANAGEMENT 

ADDRESS 

RANGE OF THE 

ENVIRONMENT 

SETTING FILE : 

COMMUNITY 

NAME, 

POLLING 

INTERVAL, 

TIME-OUT TIME 



.660 



SET THE 
CORRESPOND- 
ING HOST NAME 
BY REFERRING 
TO THE/etc/ 
FILE 



661 



SET ' Normal " 
TO THE STATUS 
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MONITORING THE MANAGEMENT RANGE 

,672 

C ^TART ) 



LOOP BY THE 
ENTRY 
NUMBER OF 
THE MANAGE- 
MENT RANGE 
TABLE 



.670 



REFER TO THE 
MANAGEMENT 
RANGE TABLE 



671 



ping 
PROCESSING 



673 



IS THERE IP 
ADDRESS 
AND IS THE 
STATUS 
OTHER THAN ^ 
"Critica!" ? 



680 



FIG.19 



674 



ISSUE AN 
SNMP 

REQUEST TO 
THE CORRE- 
SPONDING IP 
ADDRESS IN 
ORDER TO 
OBTAIN THE 
FOLLOWING 
MIB-II 
VALUES : 
sysObjecOD 
lfNuml>er 
IfType 

ifOperStatus 
AND 

IpForwardIng 



675 



YES 



IS THERE A 
RESPONSE 
TO THE 
SNMP 

REQUEST ? 



676 



SET " snmp " 
TO THE SNMP 
SUPPORT 
INFORMATION 



677 



ROUTER 
DECISION 



NO 



YES 



IS THERE A 
CHANGE IN 
THE ENTRY 



681 



STORE THE 

CHANGED 

INFORMATION 

IN THE 

COLLECTION 

DATA BASE 

MANAGEMENT 



678 



SET "nonsnmp" 
TO THE SNMP 
SUPPORT 
INFORMATION 



.679 



SET " host TO 
THE ROUTER 
INFORMATION 



( End ) 
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c 



START 



c 



3 



FIG.20 



ROUTER DECISION 



.690 



SET " host " TO 
THE ROUTER 
SUPPORT 
INFORMATION 



.694 



.693 



YES 



691 



=1 



IS THE 
VALUE OF 
ipFofwardIng 
"1- 
(gateway) ?l 



692 



YES 



IS THE 
VALUE OF 
ffNumber AT 
LEAST 
"2" 



ARE THERE A / 
PLURALITY OF / 
INTERFACES / 
OF WHICH / 
VALUE OF / 
ifType IS ( 
OTHER \ 
THAN "24" \ 
(•) AND ARE \ 
THE VALUES \ 
OF ifOperStatus \ 
ALL "r (UP) ?\no 



SET " router " 
TO THE 
ROUTER 
INFORMATION 



695 



SET ■ Normal " 
TO THE 
STATUS 



.696 



.697 



SET " Normal" 
TO THE STATUS 



SET " Marginal " 
TO THE 
STATUS 



,700 



.698 



.699 



YES 



IS THE 
VALUE OF 
ifNumber AT 
LEAST 
"2" ? 



YES 



ARE THERE A / 
PLURALFTY OF / 
INTERFACES / 
OF WHICH / 
VALUE OF / 
ifType IS / 
OTHER \ 
THAN -24" \ 
(*) AND ARE \ 
THE VALUES \ 
OF tfOperStatus \ 
A LL -r (UP) ?\no 



SET "Normal " 
TO THE 
STATUS 



.701 



\NO 



.702 



SET "Nomial" 
TO THE 
STATUS 



SET " Marginal ' 
TO THE 
STATUS 



END 



3 



') "24" OF ifType MEANS soltwareLoopback 
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Q START ) 




IS THERE A/ 
RESPONSE , 
TO THE 
ping ? 



c 



710 



END 



\NO 



FIG.21 

ping PROCESSING 
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1 2 

HIERARCHICAL, NETWORK axdadcsi management if the structure of man^ement Infor- 

MANAGEMENT SYSTEM mation to be transmitted between the manager and the 

sub-manager and the method for focusing the management 

BACKGROUND OF THE INVENTION information are not completed. In other words, one problem 

^ . ^ . , . , . , , 5 is that it is not possible to achieve a hierarchical network 

The present mvention relates to a hierarchical network Humagement system for managmg and controlling a group 

management system, and relates more particularly to a aizeiits ■ o c 

hierarchical network management system which hierarchi- ^j^^ '^^^^ according to the standard of SNMPv2 (SNMP 

caUy imuiages network resources l^agents, sub^™^^ ^^^^^^^ 2), it is possible to notice an event from one manager 

and an integration manager and which uses SNMP (Smiple ^^^^^ manager. However, no consideration is given to 

Network Management Protocol) as a commumcation pro- MerarcMcalmaimgemcaitin SNMPv2 as isthecasewithfte 

toool among them. SNMP. Accordingly, even if a sub-manager is provided 

In general, a management system of a communication between the manager and the agents, it is not possible to 

network is structured by two ^es of sub-systems, managers achieve the hierarchical management if the structure of 

and agents. A manager manages and controls network ig management information to be transmitted between the 

resources in agent unit. An agent manages and controls manager and the sub-manager and the method for focusing 

management objects such as structure information and status the management information are not completed, 

infoimation in resource unit ofthe communication network. on the oflier hand, in the OSI management system 

There exist two international standards reiadng to man- described in ief«ence literature (1), the sub-manager shoOld 

agement of communication networks. lAB (Internet Activi- 20 have both communication service of the OSI standard for 

ties Board) management standard and OSI (Open Systems achieving the OSI management standard and communica- 

Interconnection) management standard. In the networks tion service of the lAB standard for achieving the lAB 

which use these management standards, their network management standard, so that there is a problem that the 

resources are being managed in tiie following manner. sub-manager becomes large in scale. 

(1) Network management systems which use the manage- 25 In the LAN, communication service of the lAB standard 
ment standard is used, and it is a normal application of the communication 

When a communication network becomes large scale, the network that comcmunication service of the lAB standard is 

communication network is divided into a plurality of com- used between LANs. Accordingly, in the management sys- 

municatioii netwoxks (hereiiiafter to be lefeued to as "sub- tern described in r^erence literature (1), it is necessary to 

networks"), and a manager and agents are provided for each 30 use the OSI management standard althoug^i the lAB man- 

sub-netwark so that network resources of each sub-network agement standard is used in a WAN (Wide Area Network), 

are managed. There is also a paroblem tiiat tb& sub-manager is large in 

In this case, in carrying out resource management based structure, 

on the lAB management standard, an SNMP (Simple titA- Further, ftie integration manager hierarchically 

work Management Protocol) is used. The standard relating 35 manages die communicalion network, which is managed by 

to the SNMP is prescribed by RFC 1157. "A Simple Net- a plurality of management standards, by integrating the 

work Management Protocol". communication network, it is necessary to give advance 

(2) Hierarchical network management system which uses consideration to the agency and distribution, etc., forreduc- 
both the OSI man^ement standard and the lAB manage- ing the load of conversion of management information and 
ment standard 40 the load of the integration manager. However, no consider- 

A sub-manager manages each LAN (Local Area Network) ation is given to the agency, decentralization, etc., in man- 
based on the lAB management standard, and the sub- agement system of tlie reference literature (1). Hierefore, 
manager and its higher level Integration manager manages there is a problem that, as the network becomes largex in 
the network resources based on the OSI management scale, the number of management packets which are used at 
standard, as described in "Integrated OSI Network Manage- 45 the time of exchanging management information between 
ment for Distributed LAN Domains". Miyauchi et al., Infor- the integration manager and the sub-noanager increases. 

"^^^^u^^ Ji«>an June 1^3 issue, pp. SUMMARY OF THE BSTVENTION 
1420-1440, heremaitra- to be referred to as 'Reference ht- 

eratnre (1)". It is a first object of the present invention to provide a 

Reference literature (1) proposes to achieve hierarchical 50 hierarchical network management system which can hierar- 

netwoik management by combining both the OSI manage- chically manage a large-scale communication network by 

ment and the SNMP management. In other words, in this sub-managers of a simple structure based on an SNMP of the 

network, the sub-manager manages the network resources lAB management standard. 

according to the lAB man^ement standard, converts ttiis It is a second object of the present invention to provide a 
management to management based on the OSI management 55 hierarchical network management system which can trans- 
standard and transfers the converted management to the mit management information between an integration man- 
integration manager. The integration manager then manages agcr and sub-managers based on a small volume of man- 
all of the resources of the network. agement packets and which can manage a large-scale 

In managing a large-scale network, it is certainly effective communication network with low traffic and at low cost, 
to manage the network by a hierarchical structure from the 6o In order to achieve the first object, the present invention 
viewpoint of deleting management packet and simplifying is charadierized in that, basically, an SNMP is used as a 
die manager. oommmiicatioD protocol between an agent and a sub- 
However, no consid^ation is given to hierarchical man- manager and between a sub-manager and an integration 
^ement in the above-described network management sys- manager, respectively, and that a periodical collecting unit is 
tern which uses the SNMP<^&eIAB management standard 65 provided within a sub-manager ^xiilch periodicaUy collects 
Accordit^ly, even if a sub-manager is provided between the management objects of a range of setf-management through 
manager and the agents, it is not possible to achieve hier- agents which belong to fhe same management rai^e and 
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which causes a sub-manager to post to the integration 
manager the collected information at a reference request 
from the integration manager. In this system, a sub-manager 
behaves as a manager to its agents and bdiaves as an agent 
to the integration manager. 5 

In order to achieve the second object, the present inven- 
tion is characterized in that a sub-manager concentrates a 
plurality of information from each agent which is managed 
by a plurality of identifiers at a reference request from the 
integration manager and posts the concentrated information lo 
to the integration manager by using an SNMP as a commu- 
nicaticm protocol. 

According to the above unit, a periodical collecting unit 
within a sub-manager periodically collects management 
objects of a self-management range through agents which 
belong to the same management range and posts the col- 
lected information to the integradon manager at a reference 
request from the integration manager. 

In this case, the collected information is held in a format 
called MIB (Management Information Base) which is a set 
of a plurality of management objects expressed in a tree 
structure, is accessed at a reference request from tiie inte- 
gration manager and is posted to the integration manager. 

With the above-described structure, it is possible to hier- ^ 
archicaUy manage a large-scale communication network 
based on a single protocol called an SNMP of the 2AB 
standard and lliat it is possible to simplify the structure of a 
sub-manager because of the simple protocol. 

A sub-manager concentrates a plurality of management 3Q 
objects from each agent which is managed by a plurality of 
identifiers and posts the concentratediesulttothe integration 
manager. Accordingly, it is possible to transmit management 
information between the integration manager and a sub- 
manager with a snaall volume of management packets and 35 
that it is possible to reduce the load of the integration 
manager. Further, it is possible to manage a large-scale 
communication network with low traffic and at low cost. 

A network manager at the integration manager side can 
confirm agent structure information and status information 40 
of a sub-manager management range by referring to the 
periodical collection MTB of the sub-manager to meet an 
application. 

Further, when a sub-manager collects management 



objects in real time and posts the collected management 45 nation. 



FIG. 4 is an explanatory diagram for showii^ an example 
of the definition (part 1) of the periodical collet^ion MIB 
which is a sub-manager extension MTB. 

FIG. 5 is an explanatory diagram for showing an example 
of the definition (part 2) of the periodical collection MIB 
which is a sub-manager extension MIB. 

FIG. 6 is an explanatoiy diagram for showii^ an example 
of the definition (part 3) of the periodical collection MTB 
which is a sub-manager extension MIB. 

FIG. 7 is an explanatory diagram for showing an example 
of die definition (part 1) of the real-time coUecfion MIB 
which is a sub-manager extension MIB. 

FIG. 8 is an explanatory diagram for showii^ an sample 
of the definition (part 2) of the real-time collection MIB 
wtiich is a sub-manager extension MIB. 

FIG. 9 is an explanatory diagram for showing an exanqpie 
of die definition (part 3) of the real-time collection MIB 
which is a sub-manager extension MIB. 

FIG. 10 is an explanatory diagram for showing an 
example of the definition of a sub-manager extension trap. 

FIG. 11 is a diagram for showing a correspondence table 
of management objects for converting from the MIB-IT to a 
sub-manager extension MIB. 

FIG. 12 is an explanatory diagram for showing tiie 
contents of smglpNodeContext which is a sub-manager 
extension MIB. 

FIG. 13 is an explanatory diagram for showing the 
contents of smgSumTcpContext wMch is a sub-managa* 
extension MIB. 

FIG. 14 is a diagram for showing a correspondence table 
of the periodical collection MIB to be totaled. 

FIG. 15 is an explanatory diagram for showing an 
racample of the environmait setting file. 

FIG. 16 is an explanatory diagram for showing an 
example of the contents of the manageraaat range table. 

FIG. 17 is an outline PAD diagram of the monitoring 
method (main) of a management range. 

FIG. IS is an outline PAD diagram of the initial setting of 
a man^ement range. 

FIG. 19 is an outhne PAD diagram of the monitoring of 
a management range. 

FIG. 20 is an outline PAD diagram of a router determi- 



objects to the integration manager, the integration manager 
can accept the latest status of a sub-manager management 
range with small resources (CPU power and memory 
capacity) and with small number of management packets. 

Further, when the integration manager manages TCP 50 
connection information of sub-manager management range 
as a real-time collection MIB. there is an effect that it is 
possible to specify an IP node and service of high traffic 
within a management range of a sub-manager 10 with small 
operation of tiie integration manager. 55 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a system structure diagram for showing one 

embodiment of the communication network management 

system in which an integration manager, sub-managers and gQ 

agents are azranged. 

FIG. 2 is a logical relation diagram for showing a logical 

reladon^iip between the integration manager, sub-manageis 

and ^ents shown in FIG. 1. 
FIG. 3 is a functional struc^uFe diagram for showing a 65 

detailed structure of a sub-manager which is a key dement 

of the present invention. 



FIG- 21 is an outline PAD diagram of a ping processing. 
FIG. ^ is an outiine PAD diagram of a total processing. 
FIG. ^ is an updated outline PAD diagram of a manage- 
ment range. 

FIG. 24 is an outline FAB diagram of an updating 
processing. 

FIG. 25 is an outiine PAD diagjcsaa of an allocation 
method in the communication control function. 

FIG. 26 is an outline PAD diagram of an allocation 
method in the sub-manager agent function. 

FIG. 27 is an explanatory diagram for showing an 
exainple of the contents of the periodical collection MIB 
value management table. 

FIG. ^ is an outUne PAD diagram of the collection data 
base naanagement function. 

FIG. 29 is an explanatory diagram for showing an 
example of the graph display in tiie integration manager of 
a collected value which is die peaiodical ooUection MIB. 

FIG. 30 is an explanatory diagram for showing an 
exaiBple of the TCP connection to which die concentration 
function is applied. 
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FIG. 31 is an explanatory diagram for showing the format and 10c through the WAN4 and the sub-managers 19a, 10b 

of the index and value of tcpConnState of MIB-IL and 10c is connected to the LANS. In other words, the 

FIG. 32 is an explanatory diagram for showing the format integration manager 50 for hierarchically managing aU of 

of the index and value of smgSumTcpContcxt of Ihe real- resources of the network is connected to the LAN3. 

time collection MIB . ^ I^^* 2 is a diagram for showing the logical relationship of 

FIG. 33 is an explanatory diagram of the conversion ^^J^^^ sub-managors and fhe integradon manager 

between the tcpConnState of MIB-n and smgSumTcpCon- ^Z'^^'' ^^"^ comiected to the LANl and 

text of the real-time coflection MIB. 20a-l and 20a-2, the management objects are 

. , . ^ L • managed by using the SNMP of the lAB management 

10 standard and ICMP (Internet Control Message Protocol), 

of the mdex of the real-tmie collection MIB. Between the sub-manager 10« and the agent-unloaded IP 

FIG. 35 is an outline PAD diagram of the concentrating node 30a, the management objects are manned by using the 

method (main) of a management range. ICMP. To the sub-manager lOa, a collection MIB data base 

KIG. 36 is an outline PAD diagram of the concentrating 170a for holding a set of a plurality of management objects 

method (get processing) of a management range. 15 that have been collected through the agents of the manage- 

FIG. 37 is an outline PAD diagram of the concentrating lange in a format called fee MIB, (Management 

method (get issuii^) of a management range. Infomiatitm Base) which is ^pressed in a tree stracture, is 



FIG. 38 is an outline RVD diagram of tiie concentrating 

method (get-next processing) of a management range. Simflaily, between the sub-manager 10c connected to the 

FIG. 39 is an outline PAD diagram of the concentrating ^ ft .^^ent 20c, rtje management objects are 

method (next index calculation) of a management range. ^^^J^ I'^^K^ 1 management 

^„ . ^ /. r. , . standard and the ICMP. Between the sub-manager 10c and 

FIG 40 IS an outline PAD diagram of the concentrating thcagent-miloadcdIPnode30c, the management objects are 

method (get-next issuing) of a management range. manned by using the ICMP. To the sub-manager 10c, a 

FIG. 41 is a conversion diagram for converting an SNMP 25 coUection MIB data base 170c for holding a set of a pluraHty 

trap to a sub-manger extension trap. of management objects that have been collected through Ihe 

FIG. 42 is a conversion diagram for converting an SNMP agents of the management range in a format caUed the MIB 

trap to a sub-manger extension trap. (Management Information Base), (hereinafter to be referred 

FIG. 43 is an outline PAD diagram of the deleting system to as MEB format'*) which is expressed in a tree 

of an SNMP tr^. 30 structure, is connected. 

r™,T3 Tmw3wst=ra-aTSTx ^® sub-managcT lOfr and the agents 202^-1 and 202i-2 are 

DESCRlfllON OF THE PKEFERRED connected to the integration manager 50 in a similar logical 

EMBODIMENTS relationship. ""'=Sf «aiwB«r "J « smmar logicai 

One embodiment of the present invention will be FIG. 3 is a functional block diagram for showing one 

explained in detail with reference to the drawings. embodiment of the internal structure of tiie sub-manager 10, 

FKj. 1 is a system structure diagram for showing one which is structured by the following functional module: 

embodiment of the communication network to which the (1) communication control function 100 

present invention is applied. A plurality of LANs 1, 2 and 3 (2) management range monitorii^ function 110 

are connected by a WAN (Wide Area Network) 4. (3) collection data base management fimctioD 120 

Among these LANs, to the LANl, a plurality of agents (4) self-agent function 130 

20a-l and 20a-2 for managing and controlling management (5) sub-manager agent function 140 

objects such as structure information and stams information concentration function 150 

mnetwarkresource unit and an agent-unl^ded IP (Internet management function 160 

^"^li ^ connected. FUrte through the ^^^^^ ^^^^^ ^ described below, 

agents 20a.l and 20c-2. a sub-manage 10a for inans^g communication control function 100 

and controlhng the management objects withm the LANl is ^nder the lAB management standard, the protocol for 

connected. network management is called SNMP. This standard is 

To the LAN2, a plurality of agents 20d-l and 20M for prescribed by the RFC 1157. "A Simple Network Manage- 

managing and controlling management objects sudi as 50 ment Protocol". 

structure information and stams infoimatton in network 'Yhe corresponding communication control unit 100 
resource unit arc connected. Further, a sub-manager lOfr for receives an SNMP request ftom the integration manages- 50 
managing and controlling the management objects under the ^nd the sab-manager 10 itself to the coiresponding sub- 
management of the agents 20^-1 and 202>-2 is connected to manager and an SNMP trap. 

the LAN2. Rirther, an agoit 20c and an agent-unloaded IP 55 yhe SNMP request is a request from the integration 

node 30£2 are connected to fhe LAN2 and a sub-manager 10c manager 50 to the sub-manager for obtaining management 

for managmg and controlling the manag^ent objects under objects, and a request from the sub-manager 10 to the agent 

the management of the agent 20c is also connected to the 20 for obtaining management objects. 

An SNMP request that has been received within the 

Jn other words, in the LAN2, fhe man agcmcnt objects are eo communication control unit 100 is posted to the self-agent 

managed by the two sub-managers IO1& and 10<:. function 130 or to the sub-manager agent function 140 

On the other hand, to the LAN3, a plurality of agents 20-1 according to the management object identifier which exists 

and 20-2 are connected. Further, an integration manager 50 within the protocol, and the result of the requested work 

for managing and controlling the management objects under done is responded to the integration noanager 50 or to the 

the management of the agents 20-1 and 20-2 and for 6S sub-manager 10 itself which are the SNMP requesters. A 

managing and ccMitrolling the management objects under the received SNMP trap is posted to the trap management 

management of the WAN4 and the sub-manners lOo^ 10b frmction 160. 
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(2) management range monitoring function 110 munication control function 100, and the sub-manager agent 
By referring to the environment setting file 180 assigned function 140 allocates the destination from which the 

by the network manger of the sub-manager 10, the manage- requested SNMP is to be obtained based on the management 

ment range monitoring function 110 obtains the range of the object identij&er desoibed in the protocol of the SNMP 

IP address which has been assigned as the management 5 request. 

range of the sub-manager 10. The management range monl- To be more specific, according to the present invention, in 

toring ftinction 110 periodically issues an SNMP request and order to provide to the integration manager SO the manage- 

an ICMP edio request for obtaining a specified management ment information diat has been collected or concentrated by 

object defined by tiie MIB-n, to a specified IP address group the sab-manager 10« the sub-manager extension MIB which 

(regardlessof whether an agent is loaded or not), and obtains 10 includes the collection MDB and the real-time collection 

an SNMP response and an ICMP echo response which are MIB is defined. 

the result of the requests. The periodical collection MIB is the MLB of the manage- 
In this case, a polling interval of the SNMP request and ment information which has been periodically collected by 
the ISMP echo request to be periodically issued and a the sub-manager 10 from the IP node group of the manage- 
community name to be described on the SNMP protocol are 15 ment range. 

obtained by referring to the environment setting file 180. The real-time collection MIB is the concentration in the 

The management range monitoring function 11© produces MIB format of the management object information which 
Information of the MDB format from the result periodically has been prepared by the sub-manager 10 for the sub- 
obtained, stores the infonnation of the latest MIB format in manner to respond to the integration manager 50, by 
the memory, delivers this information to the collection data 20 real-time collecting and concentrating (deleting or process- 
base management function 120 and makes the collection ing unnecessary information) the management object infor- 
data base management function 120 to store the deKvered mation of the management range at the refeieacB request of 
information in the collection MIB data base 170. the integration manager 50. 

The management range monitoring function 110 also In the case of a reference request to the periodical 

enables tiie concentration function 150 to refer to the infor- 25 collection MIB, the sub-manager agent function 140 

mation regarding the IP address and status of the manage- requests the collection data base management function 120 

ment range and information of whether an agent is loaded or to obtain the MIB value and the sub-manager agent function 

not 120 obtains the result fi'om the collectioD MIB data base 

Further, the management range monitoring function 110 170. 

enables the trap management function 160 to refer to the 30 In the case of a reference request to the real-time collec- 

iofonuation r^arding the IP address of the management tion MIB, the sub-manager agent function 140 requests the 

range and index numbers. concentration function ISO to obtain the MIB value, and 

When there has been a change to the information which obtains the result from the concentration function 150. 

structures a value of the collection MEB sudi as an adtJition The sub-manager agent function 140 outputs the obtained 

or a deletion of the IP node of the management range, the 35 result to the communication control function 100. 

management range monitoring function 110 issues a sub- The environment setting file 180 refers to a community 

manager extension trap for posting the change of the infor- name (a password for deciding whether to respond to an 

mation to the integmtion manager 50. SNMP request or not) in the sub-manager agent function 

The standard of the MIB-II is prescribed in RFC 1213, 140. 

**Management Information Base for Network Management 40 (6) concentration function 150 

of TCP/IP Based Internets: MIB-ir'. When a request for obtaining the real-time collection MIB 

(3) collection data base management function 120 value has been inputted from the sub-manager agent fiinc- 
"When information which constitutes a value of the col- tion 140 to the concentration function 150, the concentration 

lection MLB has been inputted from the management range function 150 issues an SNMP request to the IP node group 
monitOEring function 110, tiie coillection data base manage- 4S whidi is loaded with an agent of the management range, 
ment function 120 stores tihds information in the collection After a response to the request has been received, the 
MIB data base 170. When a request for obtaining the concentration function 150 carries out a concentration pro- 
collection MIB value has been inputted from the sub- cessing and returns the concentrated MIB value to the 
manager agent function 140, the collection data base man- sub-manager agent function 140. 

«^ement function 120 builds eadi information diat structures 50 The environment setting file 180 refers to a commiiniiy 

die value of the collection MIB into a management object name described in the protocol at the time of issuing &.e 

foimat and responds the coUet^cn MIB value to the sub- SNMP request, 

manager agent function 140. (7) trap management function 160 

(4) self -agent function 130 When the SNMP trap is posted to the trap management 
The self-agent function 130 manages the host in which the 55 function 160 from the cormnunication control function 100, 

sub-manager 10 exists. An SNMP request to the MIB-II and the trap management function 160 smmnarizes a plurality of 

the agent extension MEB from the integration manager SO SNMP traps posted within a predetermined tune as one 

and the sub-manger 10 itself is inputted to the self-agent sub-manager extension trap and relays the sob-manager 

function 130 from the communication control function 100, extension trap to the integration manager SO. 

and the self-agent function 130 outputs the requested SNMP 60 The environment setting file 180 refers to a time interval 

to the communication control function 100. for issuing the sub-manger extension trap and a community 

The environment setting file 18© refers to the sdf-agent name and others described in the protocol, in the trap 

function 130 for a communify name (a password for decide management function 160. 

ing whether to make a response to an SNMP request or not). The logical structure of the sub-manager extension MIB 

(5) sub-manager agent function 140 65 which is the main element of the present invention, the 
An SNMP request to the sub-manager extension MIB method of determining and the method of monitoring the 

from the integration manager 50 is inputted from the com- management range of the sub-manager, the method of 
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aUocattng an SiNMP request that has been received by the 
sub-manager, the mediod of managing the collection MIB« 
the method of concentrating the collection MIB and the 
method of managing the SNMP trap will be explained in 
detail. 

(1) logical stnictuie of the sub-manager extension MIB 

According to the lAB management standard, the logical 
structure of the management object is usually defined by a 
virtual data base called a management information base. 
Hiis management information base is called MIB. 

A syntax for describing ^e MIB and a metibod for 
identifying tiie instance of a mianagement object are pre- 
scribed in RFC 1155> "Structure and Identiilcation of Man- 
agement Information for TCP/IP-based Internets" and RFC 
1212, "Concise MIB Definitions". 15 

The standard agent 20 is loaded with a management 
object which is prescribed in the MEB-IL 

The sub-manager 10 issues an SNMP request and an 
ICMP echo request for obtaining a value of a specified 
MtB-n from the IP node group of the management range, 20 
and obtains a value of the sub-manager extension MIB from 
a result of collection of the response to the requests. 

The sub-manager extension MIB is structiured by the 
periodical collection MIB and the real-time collection MIB. 

The periodical collection MIB is the MIB which is 25 
prepared from the management information that has been 
periodically collected by the sub-manger 10 from the IP 
node group of the management range. This data base is 
structured by table type management object identifiers con- 
sisting of a plurality of entries and non-table type manage- 30 
ment object identifiers. 

A table-type management object identifier has an entry in 
IP node unit of the management range, and structure infor- 
mation (IP address, host name, presence or absence of the 
loading of an agent, identification flag of the IP router, etc.) 35 
of the management range and status information such as the 
IP status, response time of the ping (ICMP echo request 
packet), etc. are held in each entry. 

When a reference request has been received from the 
integration manager 50, a method is used for reducing the 40 
number of management object identifiers to be returned, by 
putting the entry consisting of a plurality of information into 
an information unit which includes an index portion and a 
context portion. 

A non-table type management object identifier expresses 45 
the information of the contents of each of the structure 
infomiation and status infomtation of the table type man- 
agement object, totaled by the nuxnber of die IP nodes. 

A unit for totaling information for ^ving the total infor- 
mation to the integration manager 50 is provided in the so 
sub-manager 10. 

On the other band, die realrtime collection MIB is die 
concenfration in the MIB format of the management infor- 
mation which has been prepared by the sub-manager 10 for 
the sub-manago" to respond to the integration manager 50, 
by real-time collecting and concentrating (deleting or pro- 
cessing unnecessary information) the management informa- 
tion of the management rai^e at the reference request of the 
integration manager 50. 

The sub-manager 10 receives an SNMP request from the 60 
integration manager 50 and from the sub-manager itself. 
This is because the sub-manager itself can be included in the 
management range of the sub-manager 10, Particularly, 
when the sub-manager 10 has received a reference request of 
the real-time collection MIB from the integration manager 65 
50, the sub-manager 10 issues an SNMP request to the 
sub-manager itself, and responds the result of the SNMP 



after concentration. Thexe^are, the sub-manager 1# is struc^ 
tared to be able to carry out parallel processing of a plurality 
of SNMP requests. 

Examples of the definition of the periodical collection 
5 MIB which is the sub-manager extension MIB are shown in 
FIGS. 4 to 6, examples of the definition of the real-time 
collection MIB are shown in FIGS. 7 to 9, and an example 
of the sub-manager extension trap is shown in FIG. 10. 
In the definition examples of the periodical collection 
10 MIB in FIGS. 4 to 6, the following definition examples are 
shown: 

(1) number of IP nodes to be managed 

(2) number of nodes which are in critical situation with 
the sub-manager 

(3) number of nodes which can communicate with the 
sub-manager but in which tiieie easts a TCP/IP inter- 
face that is not operating 

(4) number of nodes in which all the TCP/IP intetfaces arc 
2Q operatmg 

(5) number of routers which are within the management 
range of the sub-manager 

(6) number of nodes which are loaded wifli SNMP within 
the management range of the sub-manager 

(7) a list of information relatii^ to the IP node of the 
management range of the sub-manager 

(8) entry which includes information for each IP cf tiie 
management range 

111 the definition exan^les of the reattime colledion MEB 
in FIGS. 7 to 9, the foUowuig definition examples are 
shown: 

(1) a list of the TCP oonnedion within the management 
range of the sub-manager 

(2) IP address at which the TCP connection is opened 

(3) port number used by the node which is defined by 
smgSumTcpServerlpAddress 

(4) IP address at which the TCP connection is opened (the 
other address defined by smgSiunTcpServerlpAddress) 

(5) port number used by the IP node which is ddined by 
smgStunTcpClientlpAddress 

(6) entry of the TCP connection infomiation ixiiich is 
opened by the IP node of the management range 

In the definition examples of the sab-manag«- extension 
frap in FIG. 10, the following definition exan4>les are 
shown: 

(1) a frap for posting an addition of a system 

(2) a trap for posting a deletion of a system 

(3) a relay trap 

FIG- 11 shows a correspondence table 190 for converting 
the name of a man^ement object of the MIB-II (hereinafrer 
to be refeired to as an **MIB-n object'*) which has been 
periodically and real-time collected by the sub-manager 10 
into a management object name of the extension MEB. When 
55 MIB-n objects have been periodically and real-time col- 
lected from an agent which is loaded with management 
objects of the MIB-II in a standard manner, the names of the 
MIB-n ejects are converted to names of management 
objects of the extension MIB. 

FIG. 12 shows contents 200 of smgJpNodeContext which 
is a management object of the periodical collection MIB 
after conversion. As shown in FIG. 12, smglpNodeContext 
is structured by an IP address 210, a host name 220, a status 
230, a ping response time 240, SNMP support information 
250 and router information 260. 

When the integration manager 50 periodically collects a 
management object struc^ed this way from the sub- 
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manager 10 and makes a display of the management object, 
it Is possible to display in one row a plurality of information 
relating to one agent or an IP node, so that it is possible to 
easily confirm the state of one agent or the IP node. 

FIG. 13 shows contents 300 of smgSumTcpContext 
which is a management object of the real-time collection 
MIB. As shown in FIG. 13. smgSumTcpContext is struc- 
tured by an IP address (part 1) 310, port number (part 1) 320, 
a status (part 1) 330. an IP address (part 2) 340« a port 
number (part 2) 350, a status (part 2) 360 and a seorvice name 
370. 

When the integration manager 50 pexiodicaiiy collects a 
management object structured this way from the sub- 
manager 10 and makes a display of the manageanent object, 
it is possible to display In one row a plurality of information 
relating to one TOP connection, so that it is possible to easily 
confirm the state of one TCP connection. 

In the periodical collection MJB. a management object 
name (identifier) to be used for totaling values of the 
periodical collection MLB is prepared as shown by a coire- 
spondence table 400 in FIG. 14. The periodical collection 
MIB is totaled according to the correspondence table 400. 

An example of totaled management objects that have been 
collected by the integration manager 50 at every ten minutes 
interval is displayed in a graph as shown in FIG. 29. 
(2) method of determining and method of monitoring a 
sub-manager management range 

smgCreateSystemTrap in FIG. 10 defines a sub-manager 
extension trap to be issued when an IP node has been added 
to a sub-naanagCT management range. An extension trap 
number is "1", and a corresponding index number 520a in 
a management rai^e tabic 5M shown in FIG. 16 is assigned 
to a variable list (Variable-bindings)- 

smgDeleteSystemTrap in FIG. 10 defines a sub-manager 



each set. For example, the management address i 
indicates that an IF address can be assigned from 
200.10.20.1 to 200.10.20.70. 

The community name of the management address range 
440 is used when the sub-manager 10 issues an SNMP 
request to the agent of the management range. 

An initial value (a default value) of the polling interval for 
periodically coUecting management objects of agents is set 
to five minutes, for example. An initial value of the time-out 
time is set to one second, for example. An initial value of the 
trap relay interval 450 is set to ten minutes, for example. 

FIG. 16 is a diagram for showing the format of the 
management range table 500 to be provided inside the 
management range monitoring function 110. The manage- 
ment range table 500 is structured by a control unit and a 
plurality of entries, and a maximum entry number is die 
same as the value assigned by the management range 
number 430 in FIG. 15. 

The control unit is structured by an area for storing the 
obtaining community name 510a, etc. The contents to be 
taken into this control unit from ttie environment setting file 
180 wiQ be explained below. 

The obtaining community name 4001s set to the obtaining 
community name SlOa, the setting community name 410 is 
set to the setting community name 510, the management 
range number 430 is set to the management range number 
510c, and the destination number assigned by the trap 
destination 420 and the destination IP address are set to die 
trap destination number 510^? and the trap destination table 
address SlOe respectively. Other contents will be explained 
with reference to FIGS, 17 to 24. 

FIG. 17 shows an outUne of the main processing of the 
management range monitoring function HO. At first, the 
management range is initialized (step 606) and the process- 
ing is looped until a request for ending is received (step 610). 



extension trap which is to be issued when an IP node has 35 During this period, monitoring of the management range 



been deleted from the sub-manager management range. An 
extension trap number is "2^, and a corresponding index 
number S2Aa in the management range table 500 is assigned 
to the variable list (Variable-bindings). 

FIG. IS is a diagram for showing the format of the 
environment setting file 180 which is used for determining 
the management range and monitoring range of a sub- 
manager. The environment setting file 180 includes an area 
for storing an obtaining community name 400, a setting 



(step 620), total processing (step 630) and updating of the 
management range (step 640) are carried out sequentially. 

FIG. 18 shows an outline of the initialization of the 
management range (step 600). The above-described envi- 
40 ronment setting file 180 is referred to and the mana^ment 
range table 500 is set (steps 650 and 651). 

In order to set only an existing IP address out of the IP 
addresses assigned to the management address range 440 to 
the IP address 520& of the entiy of the management range 



community name 410, a 1r^ destination 420, management 45 t^le 500, the following processing is carried out At jfirst, in 



range number 430, a management address range 440 and a 
trap relay interval 450 respectively. 

The obtaining community name 400 is the name used for 
a certification when a request for obtaining an SNMP has 
been received. This name is also used when tlie sub-manager 50 
10 issues a sub-mianager extension tr^. 

The setting community name 410 is ttie name used for a 
certification when a request for setting an SNMP has been 
received. 

The trap destination 420 is the other party IP address to 55 
which the sub-manger 10 issues a sub-manager extension 
trap, and the trap destination 420 can be assigned by a 
plurality of number like trap destinations 420a and 420&. 

The management range number 430 is the information for 



order to obtain an IP address recognized by the sub-manago- 
10. atNetAddress whitdi is an address conversion group of 
the MIB-n is obtained from the self-agent function 130 (step 
652). 

The value of the obtained atNetAddress shows a relation- 
ship between the IP address and Ihe |diysicai address. A 
blank address 520 exists in the management range table 500» 
and the processing loops during the period while the IP 
address of atNetAddress exists (step 653). 

A decision is made whether the IF address of atNetAd- 
dress is included in the management address range 440 in 
FIG. 15 (step 654), and aping is issued to only the IP address 
that is included (step 655). 

A decision is made on the presence or absence of a 



assigning a maximum IP node number to be included in the 60 response of the ping (step 656), and the IP address firom 



management range of the sub-manager 10. 

The management address range 440 is the information for 
assigning Ihe IP address of an IP node which is within the 
management range, a community name, a polling interval 
and a time-out time. The management address range 440 can 
be assigned by a plurality of sets Uke 440a and 440£? as 
shown in FIG. 15. An IP address range can be assigned in 



which there has been a response is set to the IP address 52Qb 
of the blank entry 520 of the management range table 500. 
A sub-manager eiOension trap f<x posting that an IP node has 
been added to the management range is issued to the 
integration manager 50 (step 658). 

Next, a community name relating to a corresponding TP 
address, a polling interval and time-out time are obtained 
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firom the management address range 440 of the environment 520^ of the ping of the coire^K>&ding entry 520 is set (step 

setting file 180, and the cmtmunity name 520c^ the polling 713), the oldest time 520i when the rei^onse of ttie ping has 

interval S2ftJ and the time-out time 520e are set respectively finished is cleared (step 714), and a decision is made the 

(step 659). SNMP support Information 520/ (step 715). 

Next, by referring to an /etc/host file (included in the 5 When the SNMP support information 520/ is "nonsnmp", 
information for each IP node in FIG. 6), the host name 520/ "Normal" is set to the status 520^ (step 716), and when the 

of the cxHTBsponding IP address 5206 is set (step 66V). Then, SNMP support information 520/ is "snmp", ^Macginal** Is 

•■Normal" is set to the status 520^ (step 661). set to the status 520g (step 717). 

FIG. 19 shows an outline of the momtoring of the When there has been no response to the ping (step 712)^ 

management range (step 620). lo "Critical" is set to the states 520g of the corresponding entry 

By referring to the management range table 500 (step 520 (step 718), and the oldest time 520/ when the ping 

670), the processing is looped by the number of entries 520 response finished is confirmed (step 719). 

to which the IP address S20fe is set. When the oldest time 520t exists (step 719) and when a 

During this period. Hie ping processing is carried out (step predetermined time (for example, a week) has passed (step 

672). A decision is made whether the IP addresses 520i> are 15 720). the contents S20c to 520jfe are deleted from the 

set to the corresponding entries 520 and whether the status corresponding entiy 520 (step 721) and a sub-mangedT exten- 

520^ is other than "Critical" or not (step 673), and an SNMP sion trap for posting that the IP node has been deleted from 

request for obtaining values (reference FIG. 11) of MIB-H the management range is issued to the integration manner 

(sysObjectlD. ifNumber. ifiype, ifOperStatus and 50 (stq) 722). 

ifForwarding) is issued to flie IP nodes which meed the 20 When the oldest time 520i does not exist (step 719), the 

above conditions (step 674). current time is set (step 723). 

Next, a decision is miade on the presence or absence of a FIG. 22 shows an outline of the total processing (step 

response to the SNMP request (step 675). If there has been 630). 

a response, "snmp" is set to SNMP support infoanation 52<^* At first, portions SlO^to SlUk far counting the IP address 

of the corresponding entry 520 (step 676) and a router 25 numbers in the control unit of the management range table 

decision is made (step 677). 500 are cleared, and the processing is looped by the number 

If there has been no response, "nonsnnqj" is set to the of the entries 520 (step 732). A count-up processing (+1) is 

SNMP support information 520y of the corresponding entry carried out under the following conditions only when the IP 

520 (step 678), and *'host" is set to router support informa- address is set to a correspondii^ entry 520. 

tion 520k (step 679). 30 A count-up is carried out for smg^otalManageNodeNum- 

FIG. 20 shows an outline of the router decision (step €77). ber unconditionally (step 734), for smgTotalCriticalNode- 

As an initial setting, the *1iost" is set to the router support Nxm:iber only when the status S20g is "Critical" (step 736). 

information 520^ (step 690). A decision is made to a value for smgTotalMarginNodeNuraber only when the stams 520g 

(reference FIG. 11) of ipForwarding of the MIB~ii (step is "Marginal" (step 737)^ for smgTotalNormalNodeNomber 

691), and if the value is "1" (gateway), the processing 35 only when the statas 520 is "Normal" (step 738), for 

proceeds to step 692 and if the value is other than "1" (host) smgfTotalRouteNodeNumber only when the router support 

the processing proceeds to step 698. infocniation S2^k is '^ute" (step 740), and for smgTotal- 

A decision is made to a value of ifNumber of the MIS-H SnmpSupportNodeNumber only when the SNMP support 

which shows an interface number (step 692), and if the value information 7420/ is "snmp" (step 742), respectively, 

is at least "2". the processing proceeds to step 693 and if the 40 If there is a difference between the number before the 

value is "1". '^Normal" is set to the status 520^ (step 697). totaling and the number after the totaling (step 743), the 

A decision is made whether there exist a pUsality of difference infomiation is stored in the collection data base 

interfaces in which the value of ifiype of the MIB-H is other management function 120 (step 744). 

than "24" (softwareLoopbacfc) and whether all the values of FIG. 23 shows an outline of the updating of the manage- 

ifOperStatus of the MIB-II that show the status is "1" (up) 45 ment range (step 640). 

or not (step 693). If these conditions are met, *'!router" is set At first, the cpecation is started after confirming that a 

to the router support information 520lfe (step 694) and predetecmined time^ far example, three hours, have passed 

*'Normal*' is set to the status 520^ (step 695). since the last updating (step 750). 

If these conditions are not met, "Marginal" is set to the The processing is looped for only the IP address where a 

status 520g (step 696). 50 blank entry 520 exists in the management range table 500, 

If the value of ipForwarding of the MIS-EC is other than the status 520g is other than "Critical" and the SNMP 

"1" (host) (step 691), a decision is made to the value of support information 52<V' is "snn^)" (step 751). 

ifNumber of the MIS-H which shows the interface number Next, an SNMP request is issued to the BP address S2l9b 

{step 698). ff the value is at least "2", the porocessing of the corresponding entry, for obtaining atNctAddress of 

pFooeeds to step 699, and if the value is "1**, "Nacmal" is set 55 the MIB-n (step 752). 

to the status S20g (step 702). When there has been a response to the SNMP request 

At the step 699, a decision same as tiiat of the step 693 is (step 752), the processing is looped during the period when 

carried out. If the conditions are met, '*Noimal** is set to the the blank entry 520 exists and by the number of the IP 

status S2»g (step 700), and if the conditions are not met, addresses obtained (step 754), and the updating processing 

*^arginal" is set to Ihe status 520g (step 701). 60 is caxried out (step 755). 

FIG. 21 shows an outline of the ping processing (step When there has been no response to the SNMP request 

672). (step 752), "Critical" is set in order to update the status 520g 

At first, response time 520A of the ping of the correspond- (step 756). 

Ing entry 520 is cleared (step 710), a ping is issued to a FIG. 24 shows an (Hitlineof the updating processing (step 

specified IP address (step 711) and presence or absence of a 6s 755). 

response to the ping is confirmed (step 712). When tiiere has At first, a decision is made whether tiie IP address is the 

been a response to the ping (step 712). the response time one which does not exist in the IP address 520fe of the 
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management range table 500 and whether the IP address is 
included in the management address range 440 of the 
environment setting file 180 (step 760), and the following 
IBTOcessiag is carried out only when the conditions are met. 

The IP address is set to Ihc blank entry 520 (step 761) and 5 
a sub-manger extension trap for posting that tiie IP node has 
been added to the management range is issued to the 
integration manager 50 (step 762), 

By carrying out the above processing, the sub-manager 10 
can limit the number of IP nodes to be included in the 
management range and can monitor only the exlstxi^ IP 



(3) mediod of allocating SNMF requests that have been 
received by the sub-manager 

The communication control function 100 receives SNMP 
requests from the integration manager 50 and the concen- 
tration function 150 of the sub-manager 10 and receives an 
SNMP trap from the agent 20. 

The sub-noanager agent function 140 allocates the SNMP 
requests u^iutted from the commnnication control function 
109 based on management object identifiers and relays the 20 
allocated result to the collection MIB data base management 
function 120 or the concentration function ISO. 

The main reason for providing the two agents of the 
self-agent function 130 and the sub-manager agent function 
140 is that it is necessary to process in parallel the SNMP 25 
request from the integration manager SO and the SNMP 
request from the concentration function 150. To be more 
specific, based on the parallel processing of the SNMP 
requests, when SNMP requests have been received from the 
integration manager 50 to the real-time collection MIB of 30 
the sub-manager 10, it becomes possible for the concentra- 
tion function 150 to issue an SNMP reque;^ to the self-agent 
function 130 through the communication control function 
100 as an extension of the processing and to produce a 
real-time collection MIB value based on the result of the 35 
SNMP request and send a response of the SNMP to the 
integration manager 50. 

FIG. 25 shows an outline of the method of allocating the 
SNMP requests by the management object of the commu- 
nication control function 100. The conununication control 40 
function 100 loops until an end request has been received 
(step 770). The data to be received by the communication 
control function 100 includes SNMP requests from the 
integration manger 50 and the concentration function 150 of 
the sub-manager 10, SNMP responses from the self-agent 45 
130 and the sub-manager agent function 140, and SNMP 
traps from the agents, and a decision is made which one of 
these data has been received (step 771). 

When an SNMP request has been received, a decision is 
made wh^her the object identifier is the sub-manner exten- so 
sicm MIB in order to allocate the SNMP request by the 
management object identifier within the protocol of the 
SNMP request (step 772). If the object identifier is the 
sub-manager extension MCB, this fact is posted to the 
sub-manager agent function 140 (step 773). If the identiiie]: ss 
is not the sub-manager extension MIB, this fact is posted to 
the self-agent function 130 (step 774). 

On the other hand, when an SNMP response has been 
received, a response is made to the integration manager 50 
(step 775). 60 

When an SNMP trap has been received, this fact is posted 
to the trap management :^ction 160 (step 776). 

FIG. 26 shows an outline of the method of allocation by 
the management object of the sub-manager agent function 

140. 65 

At first the sub-manager agent function 140 loops until an 
end request has been received (step 780). 



The data to be received by the sub-manager agent func- 
tion 140 includes an SNMP request from the communication 
control function 100 and a response of the result of the MIB 
value from the collection data base management function 
120 and the concentration function 150. Thearefore, a deci- 
sion is made which one of these has been received (step 
781). 

When an SNMP request has been received, a decision is 
made whether this is a request for obtaining an MIB and 
whether the community same matches or not (step 782). The 
confirmation of the conomunity name is carried out by 
comparing the community name within the protocol of tiie 
SNMP request with ttie obtaining community name 400 
shown in FIG. 15. 

When the decision conditions of the above step 782 are 
met, a decision of the operation is made (step 783). 

When the operation is get-next, the next assigned man- 
agement identifier is obtained, and this is set as the requested 
management identifier (step 784). Next, a decision is made 
whether the object identifier is the periodical collection MIB 
or the real-time collection MIB (step 785). When the object 
identifier is the periodical collection MIB, this fact is posted 
to the collection data base management function 120 (step 
786). When the object identifier is the real-time collection 
MIB, this fact is posted to the collection function (step 787). 

If fhe decision conditions of the above step 782 are not 
met, an error response is returned to the communication 
control function (step 788). 

On the other hand, when a result response has been 
received, an SNMP response is built up (step 789) and this 
response is sent to the communication control function 100 
(step 790). 

(4) method of managing the collection MIB in the collection 
data base management function 120 

The method of carrying out an allocation management of 
a management object and building up a management object 
at the time of responding an MIB value will be explained 
below. 

The collection data base management function 120 inputs 
individual information which structure the periodical col- 
lection information from the management range monitoring 
function 110 and stores the information both in the memory 
and in the collection MIB data base 170. 

The individual infomiation includes smglpNodelndex 
810 and contents 200 of smglpNodeContext, covering an IP 
address 210, a host name ^0, a status 230, a ping response 
time 240, SNMP support information 250 and router infor- 
mation 260. as shown in FIG. 27. 

The collection database management function 120 carries 
out management of infoim^on in individual information 
units which structure a management object, not in manage- 
ment object unit which is the periodical collection MIB. The 
collection data base management function 120 is structured 
to reduce the volume of data to be exchanged between the 
collection data base management function 120 and the 
management range monitoring function 110, by inputting 
only the smglpNodeLidex 810 which is the key information 
for specifying an IP node and an information unit to which 
there has been a change, for example, a status 230, from the 
management range monitoring function 110. 

When an optional IP node has been deleted from fhe 
management range of the sub-manager 10, a request for 
deleting the smglpNodelndex 810 is inputted from the 
management range monitoring function 110 and the collec- 
tion data base management function 120 changes the flag 
800 from "presence" to "absence*', thereby managing the IP 
node of the management range. 



5,651,006 

17 18 

When a refearence request to iiidividual mfbimatioii tiiat When a store request has been received, the management 

structure the periodical collection MIB has been received range monitoriag function 110 inputs to the collection data 

from, the management range monitoring function 110, the base management function 120 the smglpNodelndex 810 

collection data base management function 120 provides the which is the key information for structuring the periodical 

smgl^Nodelndex 810 which is the key information and the 5 collection MIB and the contents 200 of the smglpNodeCon- 

requested individual information to the management range text to be updated^ and retrieves the corresponding IP node 

monitoring functioo 110. When mainly the sub-manager 10 by the key information. Then, the collection data base 

has restarted, this information is also provided in order to management function 120 updates the contents 200 of the 

make theielattonship between the smg]^NodeIhdeK 810 and smglpNodeContext that is held In the memory (stqp 828). 

the IP address 210 shown in FIG. 27 to be the same as the In the case of adding or deleting an optional IP node to or 

relationship between the same before the restarting of the from the management range of the sub-manager 10, the 

sub-manager 10. collection data base management function 120 updates 

The collection data base management function 120 stores (changes) the flag 800 in FIG. 27 to "presence" or "no" 

the individual information that structure the periodical col- respectively. 

lecrion MIB in the collection MIB data base 170 in order to Then, the collection data base management function 120 

maintain the above relationship. updates the collection MIB data base 170 (step 829). 

When the sub-manf^er 10 has received a request for An allocation management can not be carried out to the 

obtaining the periodical coUedion MIB from the integration management object which expresses the totaling result of the 

manager 50, the collection data base management function collection MIB shown in FIG. 14, so that the MIB value is 

120 receives a request for obtaining the periodical collection simply updated for this management objecL 

MBB value through the communication control function 100 20 When a reference request has been received, the coUec- 

and the sub-manager agent function 140. tion data base management function 120 provides the 

The collection data base management function 120 builds smglpNodelndex 810 which is the key information for 
up a periodical collection MIB value from individual infor- structuring the periodical collection MIB and requested 
mation which structure the periodical c<dlection MIB, and individual information out of the contents of the smglpNo- 
returns the result to the integration manager 50 through the 25 deContext are provided to the management range monitor- 
sub-manager agent ftinction 140 and the communication ing function 110 (step 830). Since the allocation manage- 
control ftinction 100. ment is not carried out to the management object which 

The build-up of the periodical collection MIB refers to the expresses the totaled result of the collection MIB shown in 

assembling of each inf conation of the IP address 210 \^^iich FIG. 14, the MIB value is singly provided, 

shows one agent and IP node characteristics and IP status. 30 (5) collection and concentration method in the concentration 

the host name 220, the status 230, the response time 240 of function 150 

the ping, the SNMP support information 250 and the router When a TCP connection as shown in FIG- 30 is available, 

information 260, into the smglpNodeContext 200 which is for example, the concentration function 150 concentrates 

one management object as ^own in FIG. 27. TCP connections 1000 between IP nodes of tfaeman^ment 

FIG. 28 shows an outline of the operation of the collection 35 range and a TCP connection 1010 between fee IP node of the 

data base management function 120. management range and an TP node outside the management 

The collection data base management ftmction 120 loops range. The concentration function 150 does not concentrate 

until an end request has been received (step 820). a TCP connection 1020 between IP nodes outside the 

The data to be received by the collection data base management range. In other words, the concentration func- 

management function 120 (step 821) includes a request for 40 tion 150 concentrates the TCP connections of which at least 

obtaining the periodical collection MIB from the sub- one end is an IP node and this IP node is loaded with the 

manager agent Unction 140, and a store request and a agent 20. 

reference request from the management range monitoring FIG. 31 shows a format of the index of tcpConnState of 

Unction 110, so that a decision is made on what request has the MXB-II and the MCB value vrtiich the concentration 

been received (step 821). 4S function 150 collects from the agent of the management 

When an obtain request has been received, the collection range, 

data base management function 120 makes a decision of FIG. 32 shows a real-time collection MIB of the sufo- 

whether the request is the get-next operation (step 822), and manager 10 and this shows a format of the index of 

if the request is the get-next operation, the coUedioii data smgSumTcpContext of which MIB value is requested from 

base man^ement function 120 obtains the next assigned 50 the integration manager and the MIB value, 

index (smglpNodelndex 810) (step 823). FIG. 33 shows a relationship of the conversion between 

At the next step 824, a decision is made on the presence FIG. 31 and FIG. 32. The IP address (part 1) 310, the port 

or absence of the index by using the flag 800 in FIG. 27. This number (part 1) 320, the IP address (part 2) 34© and the port 

is mainly for the purpose of confirming the index assigned number (part 2) 350 of the index of smgSumTcpContext 

by the get operation. 55 requested from the integration manager 50 are used for a 

When the index exists, a periodical collection MIB value local IF address 1120, a local TCP port 1130, a remote IP 

to be responded is produced at step 825. If the smglpNo- address 1140 and a remote TCP poet 1150 of the index of 

deContext 200 has been requested, the periodical collecticm tq>ConnState 1100. 

MIB is built up. and if a management object which expresses A value 1160 of t<^onnState is set to the status (part 1) 

the total result of the periodical collection MIB shown in of smgSumTcpContext 

FIG. 14 has been requested, this is excluded from the Similarly, the IP address (part 1) 310, the port number 

build-up. (part 1) 320, the 3P address (part 2) 330 and the port number 

Then, the collection data base management function 120 (part 2) 340 of the index of smgSumTcpContext are used for 

responds the MIB value to the sub-manager agent function a remote IP address 1120, a remote TCP port 1130, a local 

140 (step 826). If the index does not exist, the collection data 65 IP address 1140 and a local TCP port 1150 of the index of 

base management function 120 sends an eiror response to tcpConnState 1110. A value 1170 of tqpConnState is set to 

tiie sub-manager agent fimctuMi 140 (5tq> 827). the status (part 2) 360 of smgSumTcpContext. 
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The service name 370 of smgSumTcpCoEtext is set by 
obtaining the service name corresponding to the port number 
(part 1) 320 or the port number (part 2) 350 by referring to 
die /etc/services file. 

FIG- 34 explains the sequence of the index shown in FIG. 5 
32. and this has a relation with the sequence of the entry 520 
of the management range table 500. 

In the IP address (part 1) 310, IP addresses 520* are 
arranged in order from the header of the entry. In the port 
number (part 1) 320 and the port number (part 2) 350, 
numbers are arranged in order from the smailest port num- 
ber. In the IP address (part 2) 340, the addresses 520* are 
arranged in order starting from the entry next to the IP 
address (part 1) 310 and Hie last becomes an TP address 
oatside the management ran^. 

FIG- 35 shows an outline of the main processing of the 1^ 
concentration function 150. and this processing loops until 
an end request has been received (step 1200). 

The concentration function 150 starts the operation when 
a request for obtaining the concentration MTB has been 



When the conditions in the step 1270, the step 1273 and 
the step 1274 are not met, an error is letumed (steps 1278, 
1277 and 1276). 

FIG, 38 shows an outliiie of Hie get-nexf: processing (step 
1204). 

At first, a decision is made on the presence or absence of 
an assignment of an index (step 1280). If there is an index 
assignment, the index is broken down in the same manner as 
at the step 1250 (step 1281). 

If the index has not been assigned, the next index is 
calculated and executed in order to obtain the header index 
(step 1282). 

Next, a decision similar to the one at the step 1252 in FIG. 
36 is carried out in order to make a decision wheth^ the IP 
addresses exist in the management range or not (step 1284). 

If the decision is made that only the IP address (part 1) 
exists in the management range, get-next issue is executed 
to only the IP address (part 1) (steps 1285 and 1286). 

Similarly, if the decision is made that only the IP address 
(part 2) exists in the mana^ment range, get-next issue is 



received from the sub-manager agent function 140 (step 20 executed to only tiie IP address (part 2) (steps 1287 and 



1201). At first, a decision is made whether the operation is 
get operation or not (step 1202). If the operation is get 
operation, get processing is carried out (step 1203), and 
get-next processing is carried out in other case (step 1204). 

Next, an error decision is carried out (step 1205). If there 
is no error, the concentration function 150 obtains the 
service name (step 1206) and builds up the contents of 
smgSumTcpContext to be responded (step 1207), and 
responds a result to the sub-manager agent function 140 
(step 1208). 

When there is an error, the concentration function 150 
returns an error response to the sub-manager agent fcmction 
140 (step 1209). 

FIG. 36 shows an outline of the get processing (the step 
1203), At first, the index shown in FIG. 33 is broken down 
(step 1250), and the management range table 500 is referred 
to (step 1^1) in order to malse a decision whether the IP 
address is the one included in the man^ement range or not 
(step 1252). 

When only the IP address (part 1) is included in the 
management range, get issue is executed to only the IP 
address (part 1) (steps 1253 and 1254). 

Similarly, when only the IP address (part 2) is included in 
the management range, get Issue is executed to only the IP 
address (part 2) (steps 1255 and 1256). 

When both TP addresses (part 1 and part 2) are included 
in the management range, get issue is first executed to the IP 
address (part 1) (stqps 1257 and 1258), and only when there 
is no error, get issue is executed to the IP address (part 2) 
(steps 1259, 1260 and 1261). 

When none of the IP addresses (part I and part 2) is 
included in the management range, an error is returned (step 
1262). 

FIG. 37 shows an outhne of the get issue to be executed 
in FIG. 36. 

In order to efficiently obtain the value of the MIB-II. the 
management range table 500 is referred to and a decision is 
made whether the status 520g of the IP address is ''Marginal" 
or '*Normal" and the SNMP support information 520/ is 
"snmp" or not (step 1270). 

When the above conditions are met, the management 
object identifier shown in FIG. 33 is exchanged (stq> 1271), 
and get request is issued (step 1272). 

Next, a decision is made on the presence cbt absence of a 



1288). 

If the decision is made that both IP addresses (part 1 and 
part 2) exist in the management range, get-next issue is 
executed first to the IP address (part 1) (steps 1289 and 
25 1290), and get-next issue is executed to the other address of 
the coimection only when there is no error (steps 1291, 1292 
and 1293). 

An error is returned when none of the IP addresses (part 

1 and part 2) is included in the management range (step 
30 1294). 

FIG. 39 shows an outUne of the calculation of the next 
index. 

At first, a decision is made on the presence or absence of 
the assigned index (step 1300). If the assigned index does 
35 not exist, the management range table 500 is sequentially 
retrieved from the header entry in order to obtain the header 
index. The IP address 5202? of which status S20g is '*Mar- 
ginal" or **Normal" and the SNMP support information is 
"snmp" is set as the new IP address (part 1) 310 (step 1301). 
40 "0" is set to the port number (part 1) 320. "0.0,0,0" is set 
to the IP address (part 2) 340, and "0" is set to the port 
number (part 2) 350. 

If the index exists at the step 1300, in order to efficiently 
obtain the next index, the management range table 500 is 
45 sequentially retrieved, and accordii^ to i^e sequence of 
index shown in FIG. 34, the IP address 520£> which is after 
the IP address (part 1) 310fe and of which status S20g is 
"Marginal" or "Normal" and of which SNMP support infor- 
mation is "snn^j" is set as the new IP address (part I) 310 
50 (st^ 130)5). 

FIG. 40 shows an ouHine of the get-next issue to be 
executed in FIG. 38. 

in order to efSciently obtain the value of the MIB-IL the 
management range table 500 is referred to and a decision is 
55 made whether the status 520g of the IP address is "Marginal" 
or "Normal" and the SNMP support information 520j is 
"snmp" or not (step 1310). 

When the above conditions are met, the management 
object identifier shown in FIG. 33 is exchanged (step 1311), 
60 and get request is issued (step 1312). 

Next, a decision is made to the management object 
identifier of the obtained result (step 1313). If the obtained 
result is the value of tcpConnState, a decision is made 



whether the TCP coimection is the one between the IP nodes 
response to the get request and an error decision is made 65 (step 1314). 
(steps 1273 and 1274). When the conditions are met an If the TCP connection is the one between the IP nodes, the 

obtained result is returned (step 1275). obtained result is returned (step 1315), and if the TCP 
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connection is not for between Hie IP nodes, get-next issue is Next, the trap management fdnction 160 secures a buffer 

executed again (step 1316). (step 1502). loops liie processing during the period of the 

If the obtained result is not tcpConnState at the step 1313, trap relay interval 450 (reference FIG. 15) (step 1503), and 

the next index calculation is executed and a decision is made receives the SNMP trap (step 1504). 

on the presence or absence of the index (steps 1317 and 5 In order to confkm that the received SNPM trap is the one 

131«)- When Ihe next index esxisls, get-next issue is executed ^"^^ agent 20 of the sub-manager management range, 

(step 1319), when the next index does not exist, an error is management function 160 refers to the IP address 

returned (step 1320) 5202? and the index 520a in the management range table 500 

When the conditions at the step 1310 are not met. the . . ^ . ^ i ^ 

. t +1, **u f fx^n* ^ IMA ff the received SNPM trap is the one issued by the agent 

processmg smular to those at the step 1317 to the step 1320 lo ^„ ..^ ^, . «.o«o«««,<.^* +t,» 

. ^ 20 of the sub-manager management range, the trap maoage- 

are earned out. „ . ^ . ment function 160 stores the index 520^ and the SNMP trap 

(6) method of reducing SNMPtraps m the trap management j^^^ ^^^^ ^^^^^^^^ ^ ^^^^ ^^t^^ 15^^ ^^^^^ 

tunction 160 ^he trap management function 160 builds up the sub- 

smglntermediaryTVap shown in FIG. 10 defines the sub- manager extension trap from the contents of this buffer (step 
manager extension trap to be relayed by the sub-manager 10 15 1508) and issues the sub-manager extension trap to die 
in order to reduce the number of the management packets integration manager SO (step 1509). Then, the trap manage- 
that are used by the SNMP trap, and the extension trap ment function 160 releases the buflEfer (step 1510). 
number is "3". Details of the sub-manager 10 which is the main element 

The conmiunity name 400 for obtaining the enviroimient of the present invention have been explained above. Accord- 
setting file 180 explained in FIG. 15 is also used when the 20 ing to the present embodiment, there are the following 
sub-manager 10 issues the sub-manager extension frap. The effects when the integration manager 50 refers to the peri- 
trap destination 420 is the other IP address to which the odical collection MIB and real-time collection MIB whidb 
sub-manager 10 issues the sub-manager extension trap, and s^e the extension MIB of the sub-manager 10. 
this trap destination 420 can be assigned by a pluiali^ of C^) when the periodical caUectlon MIB is referred to 
number. The trap relay interval 450 is the time for storing the 25 sub-manager 10 periodica^ issues flie ping 
SNMP trap which has been received from the agent 20 that (ICMP edio request packet) and the SNMP request p^ket to 
is tiie management range of the sub-manager. When the tiie IP node of the sub-manager man^ 
SNMP trap has been received during this period, this is ^^Z^.^* J^*^ response to these issues as the p^odical 
anangediionesub-managprextensiontnvaidisrelayedto ^ ^l^*^ ^ T ^ '^^-^^^^B^ extension 
the i^eeiatian manaeer S» 30 ' possible to make an mimediate response to a 

t4S ^ raaaagcr . «T^T»m*_ request from the integration manager SO for obtaining an 

FIG. 41 shows an outhne for convertmg the SNMP trap, SNMP. e= & 

that has been received by the sub-manager 10 from the agent The periodical coUection MIB consists of tiie manager 

20 of the management range, into die sub-manager exten- j^^^ object identifier which ©qpresscs the characteristics 

sion trap. (index, IP address, host name» IP status^ ping response time, 

A format 1400 of smglntetmediaryTi:^ wMch is the 35 SNMP loading flag, IP router loading flag) of the IP nodes 

sub-manager extension trap is structured by a trap header of the sub-manager management range in 1 (management 

1410 and Variable-bindings 1420. object identifier/IP node) and the management object iden- 

The trap header 1410 is structured by enterprise 1411, tiiler which is the individual characteristics totaled by the 

agent-addr 1412, generic-trap 1413, spedfic-trap 1414 and number of the IP nodes. Accordingly, the network manager 

time-stamp 1415, each of these elements describes sysOb- 40 at the side of the integration manager 50 can confirm, 

jectID of the sub-manager 10, IP addresses "6^' and **3" of depending on die application, the structure information and 

the sub-manager 10 and sysUpTime of the sub-manager 10. status information of the sub-manager management range by 

The contents of the received SNMP trap are sequentially referring to the periodical collection MIB of the sub- 
described in die Vari^le-bindings 1420. manager 10. 

FIG. 42 shows the details for converting the SNMP trap 45 Further, it is possible to reduce the number of the man- 

into the sub-manager extension trap. agement packets between the integration manager 50 and the 

The Variable-bin(£ngs 1420 of the format 1400 of smgin- sub-manager 10 by the number of the concentration of the 

tecmediaiyTrap is structured by mainly smglpNodelhdex periodical collection MIB. 

1430, sm£;Bnteiprise 1431, smgAgentAddr 1432, smgGen- (2) when the real-time coUection MIB is referred to 

eridTrap 1433, arngSpecdficTTrap 1434 and VacBindList 50 According to the request from tiie integration manger 50 

1435. to the sub-manager 10 for referring to the real-time coUec- 

The index number 520a of the managemrat range table tion MIB, the management object of each agent is c<dle(Ned, 

500 corresponding to agent-addr 1462 that is the IP address totaled and returned to the integration manager 50 in real 

to which the SNMP trap has been issued is described in the time. Accordingly, it is possible to accept the latest status of 

smglpNodelndex 1430. 55 the sub-manager management range with small resoiurce 

Items of enterprise 1461, the agent-addr 1462, generic- (CPU power and memory capacity) and small number of 

trap 1463 and specific-trap 1464 are described in tiie sn^lEa- manag^ncot packets. It is also possible to reduce tune exror 

terprise 1431, tiie smgAgentAddr 1432, the smgGen- between the agents. 

eridTrap 1433 and the smgSpeciflcTrap 1434 respectively. Further, by managing the TCP collection information of 

Variable-bindings 1470 of the SNMP trap that has been 60 the sub-manager management range as the real-time collec- 

rcccived is described in the VarBIndlist 1435. tion MIB, it Is possible to specify high traffic IP node and 

FIG. 43 shows an outline of the methcxl for reducing the service of the management range of the sub-manager 10 in 

SNMP trap. small operation of the integration manager 50. Further, it is 

At first, the trap management function 160 refers to the possible to reduce the number of management packets 

environment setting file 180 (step 1500) and loops tiie 63 between the integration manager 50 and the sub-manager 10 

processing until an end request has been received (step as compared with tiie case where the sub-manager 10 does 

1501). not exist 
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Further, by issuing the sub-manager extension trap, it is 
possible to efficiently transmit to tiie integration manager 50 
the changes of the sub-manager management range and 
SNMP trap received from the agent 

In the logical relation di^iram shown in FIG. 2, tbe 5 
hierarchy from the agent to the integration manager is three 
layers. However, the hierarchy is not limited to tius accord- 
ing to the present invention. 

We claim: 

1. A hierarchical netwoik management system, compds- 
ing: 

a plurality of agents, connected to a conununication 
network, for managing and controlling information, 
respectivdiy, of a plurality of resources; 

a sub-manager, having a predetermined agent group under ^ ^ 
management, for managing and controlling a portion of 
management objects of said communication netwtnrk 
through said predetermined agent group; and 

an integration manager for managing and controlling all 
management objects of said hierarchical communica- 20 
tion network through said sub-manager, 

said hierarchical network management system using an 
SNMP as a communication piotocol between said 
agents and said sub-manager and b^wcen said sub- 
manager and said integration manager, respectively. 25 
and 

said hierarchical network management system having 
periodic collecting means for periodically coUectiLag 
within said sub-manager management objects of a 
management range of said sub-manager through said 30 
predetermined agent group, and for posting collected 
information to said int^iration manager at a reference 
request of said integration manager. 

2. A hierarchical network management system according 

to claim 1, wherein said periodic collecting means periodi- 35 
cally collects management objects including noanagement 
object \^ch are not loaded with agents or \^ch are not 
started yet. 

3. A hierarchical network management system according 

to claim 1. wherein said periodic collecting means concen- 40 
trates a plurality of information relating to each agent 
managed by a plurality of identifiers and posts said concen:* 
trated result to said integration manager, at a ref^nce 
request of said integration manager. 

4. A hierardilcal network management system according 45 
to claim 1, furlSier including means in said sub-managers for 
analyzing an SNMP trap received from an agent that exists 

in the management range of said sub -manager and far 
relaying a plurality of SNMP traps to said integration 
manager as a sub-manager single ^stension tnip. so 

5. A hierarc^cal network management system aocording 
to claim 1, further including real-time collecting means in 
said sub-manager for real-time collecting a status of agents 
which belong to the management range of said sub-manager 
and for posting collected information to said integration SS 
manager, at a reference request of said integr^oo manager. 

6. A hierarchical network management system according 
to claim 5, wherein said real-time collecting means selects 
objects for a real-time collection by referring to management 
objects that have been collected by said periodical coEecting 60 
means. 

7. A hierarchical network management system according 
to claim 5, wherein said real-time collecting means concenr 
trates a plurality of information relating to each ag&nt 
managed by a plurality of identifiers and posts a concen- 65 
trated result to said integration manager, at a ref^nce 
request from said integration manager. 



8. A hierarchical netwcxk managemBut system, compds- 
ing: 

a plurality of agents connected to a first communication 
network; 

a sub-manager connected to said first communication 
network and having a predetermined agent group 
within said plurality of agents under managemeDt; 

an integration manager connected to a second communi- 
cation network and having said sub-manager under 
management; and 

a coiimiunication path for combining said first and second 
communication networks, 

wherein eadh of said agents manages and controls man- 
agement objects relating to structure information and 
status information of each of a plurality of resources, 

said sub-manager manages and controls management 
objects of said first communication network through 
said predetermined agent group, 

said integration manager accesses said sub-mant^er 
through said communication path to thereby manage 
and control a hierarchical communication netwoik 
structures by said first and second communication 
networks through said sub-manager, and 

said sub-manager includes means for functioning as an 
agent to said integration manager and for functioning as 
a manger to said agents, so that a Simple Newark 
Management Protocol (SNMP) can be eiz^loyed as a 
commntdcation pio^>col between each of said plurality 
of i^ents and said sub-manager and between said 
sub-manager and said integration manager through said 
commnnication path. 

9. A hierarchical network management system, compris- 
ing: 

a plurality of lower communication networks; 

a plurality of agents connet^ed to each of said lower 
comnmnication networks; 

a plurality of sub-managors connected to respective ones 
of said lower cormnunication networks, each of said 
plurality of sub-managers having under management a 
pfedetermined agent group. wiHiin the plurality of 
agents connected to a respective one of said lower 
communication networks; 

an integration manager connected to a higher communi- 
cation network and having said plurality of sub- 
managers under management of said integration man- 
ager; and 

a communication path far connec^g said pturality of 
lower coxnmuDication networks and said hi^er com- 
munication network, 

wherein eadi of said agents manages and controls man- 
agement objects relating to structure information and 
status information of each of a plurality of resources, 

each of said sub-managers manages and controls man- 
agement objects of a respective one of said lower 
comnuinicatlon netwoiiks through the agent group 
under management of said sub-manager, 

said integration manager accesses said sub-managers 
through said communication patii to thereby noanage 
and control management objects of a hierarchical com- 
munication netw<nfc structured by said higher commu- 
nication network through said plurality of sub- 
managers, and 

said each of said sub-managers includes means for func- 
tioning as an agent to said integration manager and for 
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functioning as a manager to said agents, so liiat a 
Simple Network Management 3Etotocol (SNMP) can be 
employed as a communication protocol between each 
of said sub-managers and said integration manager 
through said communication path. 

10. A hierarchical network management system according 
to claim 8, wherein said means for functioning as said agent 
to said sub-manager processes a management object of said 
first communication network collected through said agent 
group under management of said sub-agent into a Manage- 
ment Information Base (MIB) value for responding to said 
integration manager at an inquiry from said integration 
manager. 

11. A hierarchical network management system according 
to claim 9, wherein said means for functioning as said agent 
to each of said sub-managas processes a management 
object of said lower communication network collected 
through an agent group under management of said sub-agent 
into a Management Information Base (MIB) value for 
responding to said integration manager at an inquiry from 20 
said integration manager. 

12. A system for hierardiically managing a communica- 
tions network, con^nising: 

a plurality of resources; 

a plurality of agents, connected to the communications ^ 
network, for managing management objects of respec- 
tive ones of said plurality of resources; 

a sub-manager for managing, through management of a 
predetemuned group of agents within said plurality of 
agents, a portion of the management objects of said 
plurality of resources, said sub-manager commnnicat- 
ing with said plurality of agents using a simple network 
management protocol; 

an integration manager for managing, through said sub- 35 
manager, all of said management objects of said plu- 
rality of resources; 

a communications path connecting said integration man- 
ager to said sub-manager, said integration manager 
communicating with said sub-manager along said path 40 
using a simple network manager protocol; and 

collecting means for periodically collecting within said 
sob-manager, through said predetermined group of 
ag^ts. man^ement objects lying in a management 
range defined for said sub-manager, and for posting to 45 
said integration manager information including said 
collected management objects in response to a refer- 
ence request issued £:om said integration manager. 

13. The system recited in daim 12, wherein said man- 
agement objects include management obje<^s of structure so 
information and status information. 

14. A hierarchical network management system, oon^s- 
ing: 

a first communications network; 

a plurality of agents connected to said first commnnica- 
tions network; 

a plurality of groups of resources, each of said plurality of 
agents managing management objects of a respective 
group of said plurality of groups of resources; 50 

a sub-manager, connected to said first communications 
network, for managing- through management of a pre- 
d^eimined group of agents within said plurality of 
agents, management objects of resources being man- 
aged by said pred^^rmined group of ^ents. said 



sub-managex oommunicating at least with said prede- 
termined group of agents throng a simple network 
management protocol; 
a second communications network; 
a communications path for connecting said first and 

second communications networks; 
an integration manager, connected to said second com- 
munications network, for managing said sub-manager, 
said integration manager communicating witii said sub- 
manager through said communications path using a 
simple network management protocol and cooperating 
with said sub-manager to manage a hierarchical com- 
munications network whidi includes said first and 
second canomunications networks; and 
means, within said sub-manager, for functioning as an 
agent to said integration manager and for functioning as 
a manger to said predetermined group of agents. 

15. The hierarchical netwca:k mana^ment system recited 
L 14, wherein said management objects include 

management objects of structure information and status 
information. 

16. A hierarchical network management system, compris- 
ing: 

a plurality of lower-level communications networks; 
a plurality of sets of agents, each set of agents connected 
to a respective one of said plurality of lower-levd 
communications networks, with the agents in each set 
of agents managing management objects of respective 
ones of a plurality of resources; 
a plurality of sub-managers connected to respective ones 
of said lower-level communications networks, each of 
said sub-managers managing, through management of 
a predetermined group of agents within tiie set of 
agents connected to the lowCT-level communication 
network to which said each sub-manager is connected, 
management objects being managed by said predeter- 
mined group of agents, each sub-manager communi- 
cating with at least the predetermined group of agents 
being managed by said each sub-manageirs using a 
simple ndwork management protocol; 
a higher-level comnonnications netwoik; 
a communications path for connecting said tu^er-level 
communications network to said plurality of lower- 
level communications networks; 
an integration manager, connected to said higher-level 
communications network, for managing said plurality 
of sub-managers to control management objects being 
managed by the agents in the predeterrained groups of 
agents being managed by said sub-managers, said 
int^ration managra: commnnicating with said plurality 
of sub-managers through said communications path 
using a single network management protocol; 
wherein each of said plurality of sub-managers includes 
means for func^oning as an agent to said integration 
manager and for functioning as a manager to each agent 
in tite set of agents being managed by said eadi of s^d 
plurality of sub-managers. 

17. The hierarchical network management system recited 
in claim 16. wherein said management objects include 
management objects of structure information and status 
information. 



